1. Field of the Invention
The present invention relates generally to an improved data processing system, and in particular, to providing appropriate access in a federated computing environment to those audit logs required for fulfilling federated audit functionality in a secure, controlled manner for purposes of compliance demonstration.
2. Description of the Related Art
In today's computing environment, complex network data processing systems often are needed to facilitate work in large corporations. These complex networks may even span across regions in various worldwide locations, as well as use the Internet as part of a virtual private network for conducting business. In many instances, a federated data model is employed to allow Enterprise components to share and access information and resources throughout the network. With the federated data model, wherein multiple data sources appear as one to users, data resides and is controlled locally, and client users in the system may access the data using a directory service or links to other federated partners, regardless of the users' locations.
Within a federated environment, a single sign-on (SSO) environment is used to allow users to access third party Web sites without further authentication, as the third party Web site accepts the proof of authentications of the users presented to the third party Web site by the first Web site the users visit (and to which the user authenticated). For example, when a company employee logins to a corporate portal, an authentication interaction is initiated between the user and the corporate portal. When the user clicks on special links within this portal (for another partner's enterprise acting as third party resources to the company), a single sign-on action is initiated and the user is then single-signed on to the other partner enterprises. These other enterprises may include such third party resources such as the health care provider or 401k provider for the company's employees, but may also include other third party resources, such as supply chain management resources at a manufacturing partner. Thus, the corporate portal may include links to resources not only within the company itself, but it may also include links to other resources hosted by third parties. In an automotive industry for example, a user may be single-signed on from a supplier to the auto manufacturer, wherein the user may perform supply chain management, check inventory, check engineering design documentation, etc. In this manner, a user may perform business-related or access control-related tasks in a third party's environment based on the authentication of the user at the first entity (the identity provider).
Compliance is the ability to determine, in near real-time or after-the-fact, what events have occurred in a system, and more specifically, that the events that have been allowed to take place are consistent with an overall policy guiding allowable actions within and by the system. To check compliance of a system, audit logs are typically used to determine who has done what and when, within a system. For example, audit logs record who has accessed a resource and at what time from a security point of view. For example, when a user signs onto a workplace portal or desktop in the morning, a compliance system may be used to build a path which tracks the actions of the user and all of the applications that the user accesses in the system. Reports may also be generated on a per user basis which show what a particular user did and when the user did it. Rules may also be applied to the reports to identify if the accesses by the user are actually authorized by the system. Thus, compliance may be used to validate the system configurations in place which define what a user may access. In other words, compliance ensures that the system configurations are implemented correctly.
While compliance may be seen to ensure the ability to ensure that a security policy is enforced, compliance may also be applied to other types of policy, such as service level agreements (e.g., using timestamps on audit logs to ensure that an overall Service Level Agreement (SLA) is satisfied), legislative compliance (e.g., on control or release of privacy-related information), or even policy management itself (e.g., who changed a policy, when and how, and was it in compliance with the policy for compliance-policy-management).
Compliance is often demonstrated through audit log techniques. For example, when trying to determine if a user has correctly accessed a resource, audit logs are gathered from various components, such as from authentication services, session management services, authorization services, or applications. These audit logs are analyzed to determine if the actions are consistent with the policy governing allowable actions. This type of after-the-fact demonstration is a standard approach to demonstrating compliance and determining where compliance is broken. However, this existing approach is not sufficient in a federation environment, wherein users move from one security domain or Enterprise to another as part of their federation experience. In this situation, since the federation environment includes disparate security domains and disparate Enterprises, gaining access to the required audit logs of another federated partner is typically not possible since companies in a federated environment may not allow other companies to access their audit logs for various reasons. Thus, if an employee's company wants to build a report containing information regarding what resources the employee accessed in the federation environment, the company may only build a report for what the user did in the company's domain, since the logged actions of the user in the other federated partners' domains are not available to the company.
As an example of the need to build a complete, federated audit report, consider a federation participant acting in the role of a service provider. When a user single signs-on to the service provider, the identity provider typically includes information about the user's authentication methods as part of the single sign-on protocol (asserted within a single sign-on assertion). The service provider has no means of validating this as it does not have access to the identity provider's authentication service audit logs. In a federated audit environment, the service provider requires the ability to validate the assertions provided by the identity provider in the single sign-on assertion by validating the corresponding entries in the identity provider's authentication service audit logs. In other words, the service provider, in order to demonstrate compliance with the service provider's policies governing authentication and access, needs to consider the (relevant) information from its identity provider partner's audit logs.